intercom_user_jwt is stripped out of the payload passed to Intercom('boot', ...). If identity verification relies on providing intercom_user_jwt in the boot call (as Intercom’s standard flow does), this can lead to users being booted without verification. Include intercom_user_jwt in the boot payload (or pass window.intercomSettings as the boot object after merging user fields) so verification is reliably applied.

intercom_user_jwt is stripped out of the payload passed to Intercom('boot', ...). If identity verification relies on providing intercom_user_jwt in the boot call (as Intercom’s standard flow does), this can lead to users being booted without verification. Include intercom_user_jwt in the boot payload (or pass window.intercomSettings as the boot object after merging user fields) so verification is reliably applied.

Treating “Intercom disabled by configuration” as a rejected Promise forces callers to handle this as an error path, even though it’s an expected state. Prefer resolving as a no-op when appId is missing (and/or exposing an isEnabled() helper) so downstream auth flows don’t need to special-case this.

If the script fails quickly (onerror), boot() will still poll for up to 10s before rejecting, which delays auth lifecycle completion and adds avoidable background work. Consider making loadScript() return a shared Promise (cached across calls) that resolves on onload and rejects on onerror, and have boot() await that instead of polling; this will fail fast, simplify control flow, and avoid repeated intervals/timeouts for concurrent boots.

If the script fails quickly (onerror), boot() will still poll for up to 10s before rejecting, which delays auth lifecycle completion and adds avoidable background work. Consider making loadScript() return a shared Promise (cached across calls) that resolves on onload and rejects on onerror, and have boot() await that instead of polling; this will fail fast, simplify control flow, and avoid repeated intervals/timeouts for concurrent boots.

Logging the raw error object can inadvertently include sensitive context (depending on how errors are produced/serialized), and this path is triggered during authentication. Prefer logging a sanitized message (e.g., error?.message) and avoid dumping full objects that might contain user identifiers or token-related info.

.env.dist.local is typically a template; committing a concrete app id can cause accidental usage against the wrong Intercom workspace in local/dev setups. Consider leaving this blank or using an obvious placeholder value (with a short comment) to encourage explicit configuration per environment.

Exported useIntercom composable is never used

Low Severity

The useIntercom composable is exported but never imported anywhere in the codebase. The auth actions module directly imports boot and shutdown instead. This is dead code that adds unnecessary surface area to the module.

 

Shutdown doesn't cancel a pending boot operation

Low Severity

shutdown() only acts when isBooted is true, but if it's called while boot() is still waiting for the script to load (polling via setInterval), the pending interval is never cleared. Once the script finishes loading, the interval callback will still execute and boot Intercom with the previous user's credentials. Adding a cancellation flag (e.g., a cancelled boolean checked inside the interval) would close this lifecycle gap.

 

JWT stripped from Intercom boot call breaks verification

High Severity

The intercom_user_jwt is explicitly destructured out and excluded from the options passed to window.Intercom('boot', ...). It's only set on window.intercomSettings, but Intercom's boot API call uses its own argument object — not window.intercomSettings — for identity verification. Per Intercom's SPA documentation, the JWT must be passed directly in the boot call for authenticated sessions to work. Without it, identity verification will silently fail and users won't get an authenticated Intercom experience.